Typically, protected resources on a system or server require the user to provide some form of authentication credentials before the protected resources can be accessed by the user. For example, a user via a computer on a browser application connects to a server over the Internet and attempts to access or otherwise utilize a protected resource on the server. Before allowing access, the server verifies that the user is allowed to use the protected resource using a login process. The login process can be a simple validation process of comparing the user's authentication credentials or other information to a list of valid user authentication information. Once the login process is completed by the user and is successful, the user is authenticated and a session is established between the user and the server. As applications, systems, and server configurations have developed, however, users now commonly desire to access a plurality of protected resources including a plurality of protected resources on multiple servers. If such resources or servers do not communicate with each other, the user is forced to login to each resource and/or server individually. This is burdensome and time consuming for the user, so single sign-on methods were developed.
Single sign-on (SSO) is a form of access control of multiple related, but independent, software systems where a user logs in only once and is authenticated for multiple systems without being prompted to login to each individual system or application. Perhaps better described as single point authentication, the SSO process takes the authentication information of a user and spins off various computational activity to separately authenticate or login the user to multiple applications, systems, or servers behind the scenes. Behind the scenes authentication provides the user the appearance of seamless access to multiple protected resources after one login, i.e. after being prompted for authentication only once.
In addition to the user's convenience of logging-in only once for multiple protected resources, the SSO process provides other benefits as well. For example, SSO provides a reduction in password fatigue, reduction in time spent re-entering passwords, reduction in IT costs due to inquiries regarding passwords, security without the inconvenience of prompting the user repeatedly, centralized reporting for compliance adherence, user convenience of not remembering multiple username/password combinations for multiple systems and applications, and centralized authentication servers to be utilized for authentication purposes by all other applications, systems and servers. The SSO process, however, is also replete with vulnerabilities due to possible authentication information compromises. SSO provides access to multiple resources once the user is initially authenticated and, in a sense, provides the “keys to the castle.” The process increases negative impacts caused when the authentication information is obtained by other persons and is misused. SSO therefore requires an increased focus on protecting the users' authentication information and is generally combined with other authentication methods such as one-time passwords, tokens, and/or SSO management servers. Examples of such SSO management servers are the GETACCESS system of ENTRUST by Plano Tex., and the CA SITEMINDER system by COMPUTER ASSOCIATES of Islandia, N.Y. Such systems commonly deploy a central session management server connected to the protected resource servers. The centralized access management system enables user authentication and SSO as well as policy-based authorization, identity federation, and auditing of access to applications, portals, and other protected resources. In some configurations, these systems are hosted on a single server. In other configurations, a number of servers host the central session management system, and the individual servers inter-connect to act as a single logical server. In either configuration, the session management servers are centralized to provide one central location to check for session invalidity and a single point for managing and controlling the sessions within the system.
Traditional session management servers protect access to the resources on the servers by validating the session credentials of the user trying to gain access. The typical configuration consists of access management agents installed and running on each server hosting a protected resource, where each agent corresponds to a specific protected resource. For instance, if several enterprise applications are running on an application server, an application-specific access management agent is deployed on the server for each protected application. The application-specific access management agent is called whenever a user requests access to the specific application on the application server managed by the application-specific access management agent. The corresponding agent called intervenes in the request and collects the user's session credentials. The access management agent then communicates these session credentials to an external policy server for validation. The policy server includes policies and rules regarding authentication of a user, which can include when the user last logged in, how many access attempts have been made, and logging data related to these policy questions. The policy server evaluates these policies against the user's credentials and determines whether a user is valid. If valid, the policy server returns a form of session ID allowing a session to be created between the user and the protected application.
A benefit to this configuration is the access management agents are highly customizable for the needs of a particular server. This benefit, among the other benefits of the SSO process, however, comes at a cost. As mentioned above, a specific access management agent is required for each protected application. Additionally, an agent is required for every protected server and application on every platform and potentially even for every version of every protected resource. Thus, for one application there can be several access management agents to cover the application on different platforms and in different versions. Further, as technology evolves and a server or application is updated, the plethora of agents must also be upgraded to remain compatible with the evolving hosting software. The continual installation and upgrade process across a multitude of agents, of course, affects both hardware and software administration maintenance costs.
High-end hardware is generally necessary to efficiently run the access management configuration because the centralized access point effects and limits network performance by imposing additional network traffic via a single point of validation traffic. As users continually expect greater performance levels, any increase in the time (e.g., several seconds) it takes to respond due to network traffic loads can cause the user to give up on accessing the resource. Therefore, better hardware is required to maintain user expectations. In addition, administration of this configuration generally requires a trained and exclusive staff for managing the installation, upgrades, policies etc. associated with any old and/or new applications, which of course comes with the costs of hiring, training and keeping a full time staff. Finally, the concept of such access management is similar to that of a firewall and typically requires adhering to auditing requirements. Public, health-related, and larger companies generally spend large amounts of time and money auditing these access management infrastructures to ensure their compliance as vital enforcement points for various internal and external applications.
The cost of keeping and maintaining an access management infrastructure is necessary and useful in today's technological world. However, it can be greatly improved by reducing the burden of implementing a secure infrastructure. What is needed is an access management system configuration that still provides the benefits of SSO while reducing companies' internal hardware and software administration and maintenance costs.
Other aspects of the invention will become apparent from the following detailed description, taken in conjunction with the accompanying drawings, illustrating the principles of the invention by way of example only.